Test Driven Development

Write tests first, Implement then

24 Aug 2019 View Comments
#programming #test #driven #development #tdd

Have you ever been in a situation where a hot-fix was breaking the software even further that you had to roll back that change? I have, and it wasn’t a pleasant experience at all. We rolled out the feature, and it was essentially breaking the entire login process on the mobile for OAuth users. We rolled back our changes which involved multiple people such as ops, devs, QAs, PMs, etc. Could there be a way to prevent these show-stopping bugs to production? Turns out there is!

Simple answer is, Everyone in the team can build habits of testing, rigorously.

Test Driven Development is one of the processes that can get you in the habit.

Test Driven Development (TDD) in a nutshell suggests the tests to be the driver of producing the software. You continuously run through these tests to complete your algorithm and progress based on the feedback from the run. We usually write algorithm first and then write tests required for the algorithm. We reverse this process to complete your algorithm. Once all the tests pass, one can further refactor the algorithm to complete your code.

When Kent Back first developed TDD, he sought to narrow the gap between the algorithm decision and its feedback. TDD is the psychological process for closing this gap. When you have enough passes and fails during your tests, you are getting consistent feedback on the decision you made. That’s where you become confident with the changes you have made.

The Process

TDD Flow

TDD has a fundamental guideline for anyone starting their programming.

1. Write unit tests that will fail
2. Fix those tests to make them pass
3. Refactor: code reuse, long method, tightly coupled, large class, long parameter list, etc.
4. REPEAT until satisfied

The importance here is that you wrote tests to fail and fixed them along with refactoring.

Another important concept here is that you start with test cases that fail. And then begin developing your algorithms. And repeat this process in a short amount of time.

When to use TDD

If your project has steadily built where the result is quite apparent (we all know 1+1 is 2), TDD is probably an overkill. TDD is useful when there are uncertainties in your software. If your software is pretty simple, don’t over complicate things. However, with increasing number of users these days, we have variety of microservices and software is quite complicated. We can easily encounter frequent changes which may involve different microservices and often time we lose the confidence in making such changes.

One important benefit from TDD is that the programmer would understand well what the expected outcome when developing the functionalities. TDD helps you precisely to overcome that uncertainty. Also following TDD avoids writing redundant code.

GOOD AND BAD

There are so many pros and cons of TDD. From my experience, the pros win over. I have acquired the habit of writing tests for anything I write, which is how I gain confidence in my code.

PROS:

1. Helps programmers understand the problem fully
   It naturally enforces programmers to understand well what and why of the problem you are solving. Because without this acknowledgement, you are not going to be able to write any test cases. Test cases can help you visualize the problem. Continuously monitor the status of your code. Feedback right away. Be confident in your software.
2. Having feedback for your change is very important.
   For example, when you change something which has a dependency on a piece that has very well covered and concise tests. The changes you make to your function expects those tests pass. It will eventually lead you to be confident in your changes and adds significant stability in the code. Also, it promotes you to refactor the code and simplify as required.
3. Good for teamwork. Good for development.
   There is an implicit push on collaboration with team members because they have to share their knowledge and interact to understand their software better. It promotes writing better overall code because everyone is motivated to write a better quality of software.

CONS:

1. Reduces productivity / Increased development time
   Many companies wish to finish their tasks ASAP. However, with TDD, with the apparent reason for writing extra tests, it could initially increase development time which leads to reduced productivity. However, once TDD matures, and you get used to it, you can develop faster and have that confidence in your code.
2. Can easily trap yourself into the TDD rigid mindset
   You may start focusing on developing precise and specific tests that you can easily forget the big picture. For example, you start focusing on writing tests and its 100% coverage, but if your code doesn't align with business requirements, the tests are useless.

---